Telecommunications services provided over an IP Connectivity Access Network (IP-CAN) can be subject to charging and policy control mechanisms. This includes Quality of Service (QoS) control. Accordingly, some telecommunications systems incorporate Policy and Charging Control (PCC) architectures to provide this control. 3GPP TS 23.203 describes such a PCC architecture in respect of packet flows in an IP-CAN session established by a user equipment (UE) through an Evolved 3GPP telecommunications system, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. FIG. 1 illustrates schematically an example of the PCC architecture described in 3GPP TS 23.203 that comprises a Policy and Charging Enforcement Function (PCEF), a Traffic Detection Function (TDF), a Bearer Binding and Event Reporting Function (BBERF), a Policy and Charging Rules Function (PCRF), an Application Function (AF), an Online Charging System (OCS), an Offline Charging System (OFCS) and the Subscription Profile Repository (SPR).
The PCRF is a functional element that encompasses policy control decision and flow based charging control functionalities. The PCRF provides policy and charging control for the media components negotiated between the user terminal and the AF. The PCRF receives session and media related information from the AF and informs the AF of traffic plane events. The PCRF also provides network control regarding service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF. The PCRF can provision PCC rules and PCC decisions to the PCEF via the Gx reference point, and may provision QoS Rules to the BBERF via the Gxx reference point (for deployments based on PMIP/DSMIP protocol in the core network). Criteria such as the QoS subscription information may be used together with policy rules such as, service-based, subscription-based, or pre-defined PCRF internal policies to derive the authorized QoS to be enforced for a service data flow. The PCRF PCC decisions may be based on one or more of the following:                information obtained from the AF via the Rx reference point, e.g. the session, media and subscriber related information;        information obtained from the PCEF via the Gx reference point, e.g. IP-CAN bearer attributes, request type, subscriber related information and location information;        information obtained from the SPR via the Sp reference point, e.g. subscriber and service related data;        information pre-defined in the PCRF; and        information obtained from BBERF via the so-called Gxx reference point.        
The PCEF is a functional entity that behaves as a Policy Enforcing Point (PEP) for enforcing decisions instructed by the PCRF and the OCS. The PCEF provides service data flow detection (based on the service data flow filter filters defined in the PCC rules) to capture and analyse any user and signalling traffic, to identify the user and to capture details of the service(s) being used. The PCEF can then communicate this information to the PCRF over the Gx interface, to the OCS over the Gy interface and to the OFCS over the Gz interface. The PCEF enforces QoS control according to the QoS authorised by the PCRF. The PCEF is preferably co-located within the gateway node implementing the IP access to the Packet Data Network (PDN). As such, in a GPRS core network the PCEF is located within the GPRS Gateway Support Node (GGSN), whilst in the case of a CDMA2000 network the PCEF may be located in a Packet Data Serving Node (PDSN), and in a WLAN network the PCEF may be located in a Packet Data Gateway (PDG).
The BBERF functionality includes bearer binding, uplink bearer binding verification and event reporting to the PCRF. For example, in a GPRS core network the bearer binding mechanism associates the PCC rule with the PDP context that is to carry the service data flow. When GPRS Tunnelling Protocol (GTP) is used between the BBERF and the PCEF then bearer binding is performed by the PCEF. Alternatively, when Proxy Mobile IP (PMIP) is used between the BBERF and the PCEF, instead of GTP, then bearer binding is performed by the BBERF.
The OCS provides authorization for the usage of network resources based on the provisioned data and the user activity information it receives from PCEF. This authorization must be granted by the OCS prior to the actual resource usage. When receiving a network resource usage request, the network assembles the relevant charging information and generates a charging event towards the OCS in real-time. The OCS then returns an appropriate resource usage authorization over the Gy interface. The resource usage authorization may be limited in its scope (e.g. volume of data or duration) therefore this authorization may have to be renewed from time to time as long as the user's resource usage persists. The OCS can support time, volume and event-based charging.
The SPR contains all subscriber/subscription related information needed for subscription-based policies and IP-CAN bearer level PCC rules by the PCRF. The Sp interface allows the PCRF to request subscription information related to the IP-CAN transport level policies from the SPR based on a subscriber ID and other IP-CAN session attributes.
The Application Function (AF) is an element offering applications in which service is delivered in a different layer (i.e. transport layer) from the one the service has been requested (i.e. signaling layer). These applications require policy and/or charging control of the IP-CAN user plane behaviour. The AF therefore communicates with the PCRF over the Rx interface to transfer dynamic session information (e.g. a description of the media to be delivered in the transport layer) required for PCRF decisions, as well as to receive IP-CAN specific information and notifications about IP-CAN bearer level events. One example of an AF is the P-CSCF of the IP Multimedia Core Network (IM CN) subsystem. In the case of a P-CSCF, the information communicated over the Rx interface is derived from the P-CSCF session information (e.g. SDP when SIP is used for signalling) and it mainly includes media components. A media component comprises a set of IP flows, each of which is described by a 5-tuple, the media type and required bandwidth.
3GPP Release 11 has introduced Application Detection Control (ADC) functionality into the PCC architecture. This ADC functionality provides for requests to detect the traffic of a specified application, reporting to the PCRF on the start or stop of application traffic and the application of specified enforcement actions.
Consequently, this ADC functionality requires Deep Packet Inspection (DPI) of packets in order to monitor the payload of packets and to detect when an application is initiated/terminated etc. This ADC functionality can be provided by the PCEF, in which case the PCEF is referred to as PCEF enhanced with Application Detection Control (ADC) functionality, or by the separate TDF entity. There are two different models that can be applied for ADC; solicited and unsolicited application reporting. For solicited application reporting, the PCRF instructs the ADC node (i.e. the TDF, or the PCEF enhanced with ADC) as to which applications to detect and report to the PCRF by provisioning the appropriate ADC rules. The PCRF may also, in a dynamic ADC rule, instruct the ADC node as to what enforcement actions to apply for the detected application traffic. For unsolicited application reporting, the ADC node is pre-configured as to which applications to detect and report.
The PCRF can provision an ADC node with ADC rules by activating an ADC rule that is configured at the ADC node (i.e. using the ADC-Rule-Name AVP), or by installing a PCRF-provisioned ADC rule (i.e. using a ADC-Rule-Definition AVP within an ADC-Rule-Install AVP). The ADC-Rule-Definition AVP includes the TDF Application Identifier AVP that references the application (e.g. its value may represent an application such as a list of URLs, etc.) for which the ADC rule applies. In order to be informed as to when an application, defined by TDF Application Identifier AVP, is started and/or stopped, the PCRF can subscribe to the APPLICATION_START/APPLICATION_STOP Event-Triggers.
FIG. 2 is a signalling flow diagram illustrating an example of the establishment of an application session in which the service is a voice call over an IP Multimedia Subsystem (IMS). In this example, the user of User Equipment (UE) A initiates the voice call service, and UE A therefore generates and sends a Session Initiation Protocol (SIP) INVITE message including an appropriate Session Description Protocol (SDP) offer (e.g. specifying audio media and the offered codecs) (A1). The SIP INVITE is routed towards UE B via a P-CSCF (i.e. an AF) in the originating network (A2), and then via a P-CSCF (i.e. an AF) in the terminating network (A3). Upon receiving the SIP INVITE at UE B, UE B generates and sends a SIP 180 Ringing provisional response to UE A (A4). The SIP 180 Ringing response is routed to UE A via the P-CSCF in the terminating network (A5), and then via the P-CSCF the originating network (A6), before being received at UE A. When user B then answers the call (A7), UE B generates and sends a SIP 200 OK response, and includes an SDP answer in the SIP 200 OK response that indicates which of the offered codes are preferred (A8). The SIP 200 OK response is routed to UE A via the P-CSCF in the terminating network (A9), and then the P-CSCF the originating network (A10), before being received at UE A. The P-CSCF in the originating network therefore initiates establishment of an AF session by sending a Diameter Authentication-Authorization-Request (AAR) message to a PCRF in the originating network over an Rx interface (A11). The P-CSCF in the terminating network also initiates establishment of an AF session by sending an AAR message to a PCRF in the terminating network over an Rx interface (A12). These AAR messages include service information such as an application identifier (i.e. in an AF-Application-Identifier AVP), the codecs negotiated by UE A and UE B (i.e. taken from the SDP answer), and the flow information (i.e. in a Flow-Description AVP).
Upon receipt of an AAR message, both the originating PCRF (A13) and the terminating PCRF (A14) respond to the respective AAR messages by generating and sending an Authenticate and Authorize Answer (AAA) message. Both the originating PCRF (A15) and the terminating PCRF (A16) then perform session binding, associate the described service IP flows within the AF session information to an existing IP-CAN session, and perform the PCC rule authorization. Both the originating PCRF (A17) and the terminating PCRF (A18) then generate and send a Re-Authorization Request (RAR) message to request that the corresponding PCEF (i.e. implemented at the PDN GW) installs, modifies or removes PCC rules in accordance with the PCC rules authorized by the PCRF. Both the originating PCEF (A19) and the terminating PCEF (A20) therefore install the PCC rules received from the respective PCRF and generate and send a Re-Authorization Answer (RAA) message to the corresponding PCRF to acknowledge the RAR message. Both the originating PCEF (A21) and the terminating PCEF (A22) then initiate the establishment of a dedicated IP-CAN bearer for the service over the access network currently used by the corresponding UE. As a result, the voice call between UE A and UE B is provided over the established bearers.
A problem arises when more than one PCRF is present in an operator network. In this situation, the AF must be able to discover which of the multiple PCRFs is responsible for the IP-CAN session that is to be modified as a result of the AF session, such that the service information is sent to the appropriate PCRF (as required in steps A11 and A12 of FIG. 2). In order to solve this problem, the 3GPP standards propose introducing a Diameter Routing Agent (DRA) entity that ensures that all Diameter sessions for a certain IP-CAN session reach the same PCRF, as illustrated in FIG. 3. To do so, the DRA needs to maintain the status of the PCRF assigned for a certain UE and IP-CAN session. This status must at least include an index key and the address of the PCRF, wherein the index key must unambiguously identify a single IP-CAN session. Typically, this index key will comprise the UE IP address that is conveyed over both Gx and Rx interfaces. However, if the index key is based exclusively on the IP address, then it is not possible to support overlapping IP addresses, which are commonly used in Virtual Private Network (VPN) scenarios or multi-tenancy networks. Whilst the 3GPP standards state that the DRA can also make use of information such as the user identity (i.e. the UE Network Access Identifier) and the Access Point Name (APN), this information is not provided over the Rx interface from an IMS network, such that even this solution is not sufficient. For example, the access network will be aware of the IMSI/MSISDN and can provide this to the PCRF over the Gx interface. However, an AF such as an IMS P-CSCF will only be aware of the IMPU/IMPI and can therefore only provide this to the PCRF over the Rx interface.